I'm trying to make a VPN connection to a Windows Server 2012 Essentials server. I can successfully connect using SSTP, but I want to use IKEv2 to improve performance. However, when I try to connect, I receive the following error messsage: "Error 13819: Invalid certificate type".

The message suggests to me that the certificate being used does not have the correct EKU attributes for an IKEv2 connection. However, I have issued a certificate for the server, placed in the server's Personal Store, which includes the EKUs for Server Authentication and IP security IKE Intermediate, as specified in this tutorial (albeit for Server 2008) The certificate is self-signed, with the root authority trusted by the client computers.

What I would like to do is to find out exactly which certificate is actually being selected by the server for the IKEv2 connection. I can't see any way of verifying which is being used - I suspect the server may be selecting a different certificate without the correct EKUs. Once I am sure of the certificate being used, I could verify it on the client computers with certutil.

Could anyone suggest how I could do that?

Thanks.

Hi,

Thanks for posting in Microsoft TechNet forums.

I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

Thank you for your understanding and support.

Regards

Kevin

TechNet Subscriber Support

If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.

 

Hi,

Please refer to the article below for checking the certificate on the VPN server:

Troubleshooting IKEv2 VPN Connections
http://technet.microsoft.com/en-us/library/dd941612(v=ws.10).aspx

If you have any concern, please feel free to let me know.

Thanks.
Best Regards,
Annie Gu

• Marked as answer by Microsoft contingent staff Tuesday, December 04, 2012 6:47 AM
• Unmarked as answer by Andrew Spinner Tuesday, December 04, 2012 9:43 AM

Hi Annie,

Thanks for your response. I've already seen the article, and my certificate already appears to match all the requirements mentioned in it. My specific error, 13819, is not mentioned.

What I want to do is to find out how to determine which certificate is actually being used. I know that a valid certificate is available, I just don't know whether the server is correctly using it. Is there a way to specify which certificate the server should use? I was under the impression that the server simply selects whichever certificate it finds to be valid (has the correct EKUs, etc.).

Thanks.

• Edited by Andrew Spinner Tuesday, December 04, 2012 9:44 AM

An update: Following the instructions here, I have changed the SSTP certificate (although it was working fine) to the certificate I have issued for IKEv2 use, since I believe I can use it for both of them. I have also deleted the old SSTP certificate, which should mean that there is only one certificate that can be used for the connection.

There is no change - SSTP still works fine, but IKEv2 still fails with "Error 13819: invalid certificate type."

Is there any way I can gather more information about the problem, beyond the rather basic error message?

I still suspect that the IKEv2 connection is somehow using the wrong certificate.

Thanks,

Andrew

• Edited by Andrew Spinner Friday, December 07, 2012 2:35 PM

Hi,

Which type of templated you used for applying the certificate?

As I know, there are three versions to apply the certificate: version1, version2 and version 3.

Usually,the version 3 template doesn't apply to some application. If you used the version 3, can we change to version 1 or 2 for test?

Thanks.

Annie

Hi,

Which type of templated you used for applying the certificate?

As I know, there are three versions to apply the certificate: version1, version2 and version 3.

Usually,the version 3 template doesn't apply to some application. If you used the version 3, can we change to version 1 or 2 for test?

Thanks.

Annie

Hi Annie,

To issue the certificate I've been creating a template as outlined here: http://technet.microsoft.com/en-us/library/dd637815%28v=ws.10%29.aspx#bkmk_step4

I can't see any reference to version 1/2/3 in the details of the certificate template. Where should I look for this?

Thanks,

Andrew

Hi,

Can we delete all the other certificate except this problematic one on a test client?

I would like to test if the certificate will be incorrectly taken by the computer or not.

Thanks.

Best Regards,

Annie

I'm glad to see that someone else is having the same issue, and is working on the result.  I'd be happy to do some tests as well on our server if that would help.

Symptoms are similar in that IKEv2 will fail with the same error 13819 from my Windows 8 desktop, however, it connects just fine from my Windows 7 desktop.  Clients who connect to our network via VPN to perform some tasks have been reporting similar issues, however, it's not as clear cut as Win8 never works and Win7 always works.  They're getting failures on Windows 7 as well.

Certificate wise, this server has a wildcard certificate on it from Thawte, for *.ourdomain.com, and VPN connections are made to a hostname that matches this wildcard.  SSTP has no problems at all.  PPTP is functioning as well.  We aren't using L2TP/IPSEC.  The server is RRAS on Windows Server 2012.

I recently had the need to do some internally signed certificates for some client's test sites, so I have installed certificate services and made this a standalone CA, so there's a self signed ca certificate (ca.ourdomain.com), which does overlap with the wildcard certificate, but since the wildcard one doesn't allow certificate signing the self signed one is in there.

Under RRAS there's an option with SSTP as to which certificate to use, nothing of the kind for IKEv2.  Just to make sure there's not a certificate problem with the wrong one being automatically chosen, I've installed the CA self signed certificate as a trusted root certificate on my Windows 8 desktop, and attemtped to establish a VPN to ca.ourdomain.com instead of vpn.ourdomain.com.

The server has two IP addresses configured on the LAN adapter and I've checked with "netsh http show sslcert" to ensure they're bound to the correct IPs.

I will double check that last part though since there were some hotfixes applied recently and a server reboot.  I have noticed these bindings change from time to time.

Alex.

I'm glad to see that someone else is having the same issue, and is working on the result.  I'd be happy to do some tests as well on our server if that would help.

Symptoms are similar in that IKEv2 will fail with the same error 13819 from my Windows 8 desktop, however, it connects just fine from my Windows 7 desktop.  Clients who connect to our network via VPN to perform some tasks have been reporting similar issues, however, it's not as clear cut as Win8 never works and Win7 always works.  They're getting failures on Windows 7 as well.

Hi Alex,

Interesting to hear your experience. I'm also having problems with connecting on a Windows 7 client, but it's interesting that some of your clients are successfully connecting.

I had assumed that "invalid certficate type" referred to the server certificate. Perhaps that's not the case, if some clients can connect. Is it an intermittent fault in your case? Do some clients connect sometimes, but not always?

@Annie: Which certificate do you mean for me to preserve on the client? In theory, there shouldn't need to be any certificates on the client (aside from the root authority's), surely?

Andrew

Hi,

Can we delete all the other certificate except this problematic one on a test client?

I would like to test if the certificate will be incorrectly taken by the computer or not.

Thanks.

Best Regards,

Annie

Hi Annie,

I have just tried to connect through the StorngSwan VPN client on an Android phone. In the log, I can see I'm receiving the same error - 13819. There are no certificates installed on the phone.

Andrew

I am afraid I am still experiencing this problem. How can I confirm which certificate is being selected by the server for the IKEv2 connection?

Thanks,

Andrew

to run IKEv2 you need the following EKUs on both server and client certificates. The machines select certificates automatically, the best option is the a), if not present, they proceed to the next b) and c):

a)IPSec IKE Intermediate (IPSec Protection) 1.3.6.1.5.5.8.2.2 + Server Authentication + Client Authentication b)IPSec IKE Intermediate + Client Authentication c)Client Authentication

As you may see, both client and server require Client Authentication EKU in the certificate. If you include Server Authentication and IKE Intermediate, you will get more exact match.

ondrej.

to run IKEv2 you need the following EKUs on both server and client certificates. The machines select certificates automatically, the best option is the a), if not present, they proceed to the next b) and c):

a)IPSec IKE Intermediate (IPSec Protection) 1.3.6.1.5.5.8.2.2 + Server Authentication + Client Authentication b)IPSec IKE Intermediate + Client Authentication c)Client Authentication

As you may see, both client and server require Client Authentication EKU in the certificate. If you include Server Authentication and IKE Intermediate, you will get more exact match.

ondrej.

Hi ondrej,

Thanks for the reply. I've reissued the certificate with the Client Authentication EKU, but it hasn't made any difference.

Please note that I'm not using machine certificates on the client for authentication - I want to use Secure Password (EAP-MSCHAPv2), which is working when I connect through SSTP. However, the server seems to be determined to use certificates for client authentication - when I log using wfp, in the wfpdiag.xml file I can see that the authentication method listed is <mmAuthMethod>IKEEXT_CERTIFICATE</mmAuthMethod>. As I understand it, this should not be the case.

How can I get the server to accept EAP-MSCHAPv2 authentication?

Thanks,

Andrew

I actually don't think it is possible to have ikev2 without client machine certificate. According to my understanding, there are two distinct authentications. First, the client machine needs to establish ikev2 tunnel. For this, you need two ikev2 certificates - one on the VPN server, the other on the client machine - in the machine profile, not in user store, these certificates must adhere to ikev2 requirements. Once your client computer has ikev2 channel established, only then come PPP authentication - in your case the desired eap-tls with password. For this, you need to have a tls server certificate on NPS/RADIUS (in its policy, ragardless it is the same machine as the VPN server) - this would be tls "server authentication" certificate, again stored in the machine store and selected in the NPS network policy in the eap-tls settings.

I actually don't think it is possible to have ikev2 without client machine certificate. According to my understanding, there are two distinct authentications. First, the client machine needs to establish ikev2 tunnel. For this, you need two ikev2 certificates - one on the VPN server, the other on the client machine - in the machine profile, not in user store, these certificates must adhere to ikev2 requirements. Once your client computer has ikev2 channel established, only then come PPP authentication - in your case the desired eap-tls with password. For this, you need to have a tls server certificate on NPS/RADIUS (in its policy, ragardless it is the same machine as the VPN server) - this would be tls "server authentication" certificate, again stored in the machine store and selected in the NPS network policy in the eap-tls settings.

Hi Ondrej,

Thanks for your reply. I'm using EAP-MSCHAPv2, not EAP-TLS, by the way. May I ask you, are you 100% sure that the client machine also needs a certificate? You see, this IKEv2 connection is now working on a Windows 7 client that does not have a client certificate. Yet if I try the same connection details on a Windows 8 client, I still get error 13819. The only difference I can see is that in Event Viewer, on the Windows 8 client that fails, it says that "The user SYSTEM dialed a connection", even if the connection was only created for my own user account, whereas the Windows 7 client says something like "The user WORKPC/Andrew dialed a connection." I don't know it it's relevant, but it's the only way I can see that it differs.

If you have some documentation pointing to the need to have certificates on both client and server, I would appreciate seeing it.

Thanks,

Andrew

It's been three months and I still haven't found a solution. It works on a Windows 7 client but not on Windows 8 clients, both of which seem to be set up the same way. What further testing can I do? Is this a bug in Windows 8?

Hi Ondrej,

Interestingly, today I looked in the server's certificate store again and saw two certificates for my RRAS server's external name (e.g. vpn.microsoft.com), one being my old certificate with just the EKUs for Server Authentication and IKE Intermediate, and the other having Client Authentication as well.

I deleted the one with all three EKUs, and my Windows 7 client stopped working - with error 13819.

So it looks as if the Client Authentication is needed. However, it still won't work on Windows 8.

Furthermore, there may be another issue here, because when I re-issued the certificate with all three EKUs (and deleted the one with 2 EKUs), my Windows 7 client won't connect, even though it should be just the same set-up as before.

I suspect that the server is still somehow using the wrong certificate - maybe one of my other server certificates. How can I tell which certificate it is selecting?

Thanks,

Andrew

Same issue.

Win 2012 server, with latest updates, Win8 with latest updates. Cant make a ikev2 connection!

Any solution? Get the same error:

Error 13819: Invalid certificate type

I think I've managed to resolve it, finally. I confess I'm not entirely sure of the steps, but this is my guess as to the problem: there's some sort of mismatch between the certificate that is issued to the server (e.g. vpn.mydomain.com) and the certificate for the certificate authority (e.g. DOMAIN-SERVERNAME-CA) that resides on the client.

Although both the server and the client had those respective certificates, the server was using a certificate for itself that had been issued when the certificate authority was using a earlier version of the certificate.

What I did, I think, was to renew the certificate for the certificate authority (Certificate Authority -> DOMAIN-SERVERNAME-CA -> Renew CA Certificate). I'd done this before, so for all I know, this might have actually caused the problem originally; I don't know.

On the client computer, in the Trusted Root Certification Authorities folder of Local Computer, there were several DOMAIN-SERVERNAME-CA certificates. The client then needed to have only the one that corresponded to the most recent issue of the CA certificate. I checked the Valid From date to determine which it was. I deleted all the other DOMAIN-SERVERNAME-CA certificates in that folder on the client (actually just moved them into the "Other People" folder).

The vpn.mydomain.com certificate on the server also had to be issued when the CA was using its most recent certificate issue - again, this can be checked by looking at the Valid From date. You may have to reissue it if it was issued under a previous CA certificate.

After that, IKEv2 connections worked. My theory is that the server was presenting its most recent vpn.mydomain.com certificate for authentication to the client, but it failed when the client tried to verify it with its CA certificate, due something not matching up (since the client was trying to use an older CA certificate).

Error 13819 remains a pretty undescriptive error message.

• Marked as answer by Andrew Spinner Wednesday, January 08, 2014 11:25 AM

Although this question is already answered, I was experiencing a similar symptoms but had a different cause.  I had issued a certificate to the server for IPsec IKE Intermediary as well as Server Authentication.  The subject name matched the server, and had an alternate subject name for the external DNS name used by external clients.  Clients received error "13819 Invalid Certificate Type"

Ultimately, RRAS was selecting the wrong certificate.  There was another machine certificate marked for <All Purposes>, and RRAS was selecting that one in preference to the one I had created.  I had to delete the <All Purposes> certificate, and then RRAS started using the correct certificate.